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This paper will review lessons learned for space transportation systems from the 
viewpoint of the NASA, Industry and academia Space Propulsion Synergy Team (SPST). 
The paper provides the basic idea and history of “lessons learned”. Recommendations that 
are extremely relevant to NASA’s future investments in research, program development and 
operations are provided. Lastly, a novel and useful approach to documenting lessons learned 
is recommended, so as to most effectively guide future NASA investments. Applying lessons 
learned can significantly improve access to space for cargo or people by focusing limited 
funds on the right areas and needs for improvement. Many NASA human space flight 
initiatives have faltered, been re-directed or been outright canceled since the birth of the 
Space Shuttle program. The reasons given at the time have been seemingly unique. It will be 
shown that there are common threads as lessons learned in many a past initiative. 


I. Introduction 


N ASA’s space flight programs have had an interest in lessons 
learned since the start of space flight. In 1971, with the 
Apollo missions to the Moon nearly over, NASA published the 
“detention and Application of Saturn Experiences to Future 
Programs”. This is an example (Figure 1) of an early attempt at 
documenting lessons learned, summarizing and organizing bits of 
wisdom. This memorandum was a practical guide full of details 
that might be overlooked by someone new to the field of launch 
vehicles and infrastructure. Under “Lines and Ducts” was a 
lesson about “Stainless Steel Ducting”, observing that corrosion 
of welds could be a problem, unless one was to “avoid use of 
carbon steel wire brushes during fabrication”. 

Leaping ahead to today (Figure 2), the internet has replaced 
the memorandum of yesteryear as a way of gathering up lessons 
learned using such a “bottoms-up approach”. Lessons learned can 
be submitted or searched for on the internet at the 2 NASA 
Engineering Network. The term “bottoms-up” is used here, as the 
lessons are not asked for in the context of any higher levels goals 
or needs that guide, organize or prioritize the information. The 
term "top-down” approach will be used to refer to using goals 
and needs to generate and prioritize lessons learned. 
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Figure 1. The earliest of lessons learned 
attempts. Compiling the experience of 
individuals by parts or sub-systems categories. 
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Figure 2: A more recent attempt at gathering lessons learned, now electronic. The NASA 
Engineering Network asks users to submit their experience electronically, easeing some 
search capability. 


Not all lessons leamed are technical. Wemer Von Braun wrote of 2 3 management practices in the early days of 
NASA, including recommendations about politics and the relation to budgets, preserving in-house capabilities, 
organizational sizes, and good communication in project teams. Such lessons can be referred to as “programmatic” 
lessons in NAS A-speak, or as “management” lessons or “business practices” in more general terms. 

Realizing that categories can help better communicate lessons leamed, as if to say these drivers, causes or factors 
differ in basic class from all these other ones, these are a different “dial” to affect the outcome, projects may 
categorize lessons into buckets. The DC-X program categorized its Wessons leamed by (1) management, (2) 
technical and (3) operations and supportability. Common threads show that NASA and industry tend to use the word 
“technical” to talk about how a system was designed or manufactured, as well as operated. 

The struggle is to define useful categories and further breakouts of the “technical” vs. “management” lessons, 
while realizing that even these two broad categories may be inadequate to the entire task. For example, management 
of an enterprise (more than one large program) or even just one large program across very long time frames, easily 
creates a third class of lessons leamed, Strategic lessons, very much apart from the lessons that a sub-project would 
surface. Similarly, lesson categories for management might also diverge from “leadership” lessons given distinctions 
there. 

If a lesson is to be “ 6 knowledge or understanding gained by experience” and if “the experience may be positive, 
as in a successful test or mission, or negative, as in a mishap or failure” there is no need to be constrained to only a 
technical list, a detailed observation or a bottoms-up perspective. In reviewing traditional references, lessons leamed 
are seen to be detailed observations about some problem, or success, and a cause that was seemingly causal. The 
question “why is the sky blue” is too often not asked five times, leading to documenting only immediate causes. An 
alternative to the bottoms-up collecting of lessons leamed is a “top-down” approach, using a process that is “goal” 
and “need” driven rather than “project” driven. Either approach requires a well-defined structure for categorizing to 
exploit the knowledge best. This alternate perspective on lessons leamed is provided in part as a response to the 
failure of lessons leamed to be leamed, and the tendency of most lessons leamed documents to largely gather dust 
on the shelves (or today, in databases) for lack of a larger context and purpose. 
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II. Background, the Space Propulsion Synergy Team 

The current Space Propulsion Synergy Team (SPST) traces it’s origins to 1991 and the chartering of a group of 
NASA, industry, university and aerospace related stakeholders by then NASA Headquarters. The goal was to 
develop innovative engineering processes that could meet the challenges of the day by enlisting the diverse 
experience of the team members. 

The SPST first emphasized that while access to space for cargo or people had numerous management and 
technical challenges, from development, through design and manufacture, all the way to launch site processing and 
in-space operations, the real need to improve lie elsewhere. The greatest need identified for improvement was not in 
reaching LEO, it was in making future access to space more affordable, safer, reliable, widespread and routine. 

Getting to space was already possible. The semi-reusable Shuttle, and many other expendable launch systems, 
US or foreign, could all get to Low Earth Orbit (LEO) and beyond. Decades of investment had established robust 
data, infrastructure, and workforces" leading to wholly new industries and markets worth hundreds of billions of 
dollars a year. Humans had been to the Moon and back, and in-space operations stretched out to the edge of the solar 
system. The Global satellite infrastructure today provides for images of our Earth and its weather, for 
communications, television, radio and global positioning. Given enough time, money and the right organization to 
accomplish the task, access to space was not an impossible problem. It was an engineering and scientific challenge 
to repeat and enhance. This difference between a challenge and what needed to be focused on for improvement 
would become clearer as the SPST began its work focused on organizing improvement “needs” across categories of 
“-ilities”, those items so many lessons try to relate to such as reliability, affordability and so on. This distinction 
between getting to space and improving access to space is best contrasted when considering research and 
development (R&D), early design decisions in new programs, and technology demonstrations using existing systems 
vs. on-going business. 

• The “-ilities” 

o Affordability 
o Reliability / Safety 
o Maintainability 
o Supportability 
o Operability 
o Flight Rate Capability 

Eventually numerous discrete pieces of work by the SPST would be accomplished along the previous lines of 
investigation. The SPST continues as an ad-hoc organization bringing together senior, experienced personnel from 
NASA, industry and academia to consider, define and communicate what are essentially lessons learned from a top- 
down, goals and needs driven perspective. When considering the multi-faceted question of how to one day achieve 
routine, affordable, reliable (and safe) access to space a host of other questions become clearer that lend 
understanding and wisdom useful for setting direction. 

The discrete tasks that have been undertaken by the SPST, with relevance to lessons learned, include: 


A. Structured Prioritization Process for Decision Making Support 

Organizing when communicating useful experience is crucial to avoiding the syndrome of creating endless hit 
lists, a dictionary, or a database of detailed to-do’s within contexts that are so specific to time and place as to be 
overwhelming or useless. Among the first tasks chartered to the SPST was a technology prioritization process. 
However, in order to achieve such a prioritized technology listing devoid of a specific architecture it was first 
necessary to re-think the process of “prioritizing”. 

The result was a structured systematic process: 

Step 1 : Identify the attributes of a space transportation system; system meaning flight and ground elements, with 
attributes varying depending on if the system was in the R&D phase, the acquisition phase, etc. 

Step 2: Prioritize the attributes, using a score based on the importance, the need to improve, and the 
improvement required relative to the current state of the art. 
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Step 3: Prioritize measurable criteria, using cross-correlation to the prioritized attributes. In this way tangible 
drivers or the lessons to take forward, could be ordered to surface the most important, actionable items that would 
affect the attributes. The “few” would be separated from the “many” (aka Pareto principle). This process, also know 
as a Quality Functional Deployment or “QFD” is essentially about connecting the “why”, “what” and “how” in 
going about improvements, as shown notionally in Figure 3. 



Figure 3: A Notional description of a technology prioritization process. 

This assists in connecting why all the way to how. 


A first lesson in all this, applicable to any improvement, initiative or investment decision was to be clear on 
“why”. Determining “why” for the early SPST centered on finding the lessons that would improve the “-ilities” of 
future space transportation systems. It was a given to the team members that “the 8 success of expanded human 
presence and commercial activity in space hinges on the affordability of future space transportation”. 

A first lesson learned then, in attempting to gather, document and communicate experience, was to clearly 
understand why, what and how, and to prioritize the experience using structured, semi-quantifiable methods. 
Brainstorming has its place, as does any bottoms-up process of collecting inputs from subject matter experts, but 
within a broader picture of limited resources it is important to be structured in the decision-making steps prior to 
making investments. 

Among the lessons surfaced as priorities applicable to space transportation design and acquisition were: 

1 . Reduce the number of toxic fluids 

2. Increase system margin 

3. Increase the built in test capabilities of systems 

4. Reduce the number of confined, and/or purged spaces 

5. Reduce the number of different propulsion systems and engines 

6. Reduce the number of unique stages 

7. Reduce the active ground systems required 

8. Reduce the number of purges 

9. Reduce the number of potential leakage / connection / interface sites 

10. Reduce the number of active systems to keep a safe system 

1 1 . Reduce the number of different fluids 

Notably, many of these are specific versions of more recent themes like “commonality” in design or 
“simplicity”, but in a much more useful, focused format, stemming from a process that has surfaced a quantifiable 
driver, based on a goal. Fluids can be counted in existing systems. They can be counted in proposed system designs. 
Are there 25% fewer different fluids in a proposed design vs. an existing baseline (assuming similar capability)? The 
simpler vehicle will make significant headway on both up-front and later recurring costs. This is a tangible, clear 
driver, avoiding vagueness, making clear if a design is the same as what has come before vs. better. Later SPST 
documents would explain each of these measurable criteria in the form of a guide, equivalent to lessons learned 
focused on significant improvement around affordability and other “-ilities”. The ability to take all such criteria for a 
whole “score” of any concept, architecture, or technology A vs. B or C would also be a crucial outcome linked to 
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being a semi-quantifiable process (without which the structure of all this knowledge would lose significant 
usefulness). This process lends itself to an objective function being developed that is useful, usable and has been 
used. 

B. Functional Analysis 

Follow-on work by the SPST took the question of “how” further, organizing knowledge about a system 
functionally. Traditionally, NASA and its contractors use the work breakdown structure or “WBS” lists the purpose 
being to divide and conquer. Unfortunately, this approach is frequently related to “Weight Breakdown Structures” at 
detailed levels as the item to be built, acquired, or operated has sub-systems such as propulsion, thermal protection 
systems, a fuel cell, etc where “work” and “weight” organize in parallel to each other. Ultimately even 
organizational charts assign personnel according to similar if not identical areas that breakout the parts of a launch 
vehicle and its ground systems infrastructure. All of these breakdown structures are attempts to decompose a thing 
into smaller and smaller pieces on the theory that smaller pieces are more easily understood, managed, built and 
operated. The idea is to reduce interactions to manageable levels, increasing specialization, with ulterior motives 
such as quality control. Modem manufacturing concepts are versions of this breakdown of a process step by step to 
make an item part by part. The downside of such decomposition becomes encouraging complexity by reducing the 
capacity of the process to identify (1) duplication of parts or processes and (2) innovative opportunities among parts 
and processes to join up, become a single module, or otherwise improve capability while reducing cost. 

In contrast, the SPST innovation about “how” a launch vehicle and its infrastructure carries out it’s functions 
was to avoid jumping too quickly into design solutions before further understanding those functions. Common 
functions can then be addressed with greater integration in a design, thereby addressing measurable criteria of the 
sort outlined previously. 10 Extensive tables were developed along these lines as shown in Figure 4. 
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Figure 4: A functional breakdown structure for organizing design work. Rather than use 
weight or the work to make a product, the task to be accomplished by the product is used as the 
focus. 
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To see this more clearly by way of example, an Orbital Maneuvering System and a Reaction Control System are 
both sub-systems by which work can be assigned, in which buckets of allocated weight can be tracked (engines, 
plumbing, gases, electronics, actuators, etc) and for which people are assigned responsibilities. Functionally if the 
two sub-systems are called “in-space propulsion” the chance arises from taking this different perspective to join up 
the hardware from each system to the common task (“in-space propulsion”), resulting in less hardware. Tanks may 
be common, the same and fewer tanks feeding both engines and thrusters. 

In summary, a “functional” view is one where opportunities for both improvement and real integration (at the 
shared hardware level) can be both derived and better addressed. This is in contrast to the traditional approach that 
tears systems apart to a degree that integration really becomes just the remaining coordination among sub-systems 
that have been disconnected from each other to the maximum extent possible. The traditional attempt at reducing 
sub- systems interactions actually increases overall complexity as measured by parts count proliferation, with all its 
attendant ill effects. The functional view offers another innovative departure point for defining more affordable, 
reliable, routine access to space. 

C. Life Cycle Cost Control Lessons 

Having stressed affordability since its inception, the SPST most recently delved into the topic of life cycle cost 
control methods. SPST member experience surfaced the analogy of controlling costs in a manner similar to the way 
weight or performance is treated in launch vehicle programs. Design to life cycle cost should be a rigorous process. 
The foundation must be implemented and demonstrated during the early part of the vehicle design program. It is a 
process where trades-offs among development, operational, performance, schedule, risk, DDT&E costs, and life 
cycle costs must be addressed on a continuing basis. An ability to control costs within stringent total program and 
fiscal constraints must be demonstrated early in the design development phase and must be carried through until the 
last day of operation of the vehicles developed under the program. 

Key features of a Design to Life Cycle Cost Management process would include: 

1. Cost credibility through the use of extensive cost databases to develop initial values and operation cost 
models to assure the credibility of initial, early estimates. 

2. Assessing annual funding constraints strategically; exploring alternative system concepts. 

3. Use of a Design to Life Cycle Cost Management manager reporting directly to the program manager, 
providing a high level, single point of contact. 

4. A Design to Life Cycle Cost Management process which is an integral part of a performance 
management system; assuring an integrated cost management system that is coupled with the technical 
performance measurement system to enhance the early detection of unfavorable trends. 

5. Cost effective design solutions through system engineering control of the technical performance and 
operation cost assessments; 

6. Early establishment of realistic, yet rigorously defined cost objectives within highly visible 
management processes and discipline. 

There should be a focus on both development and operational cost containment. If system cost projections 
exceed target values, design trades should be initiated to redefine system design characteristics to a level that 
supports system costs requirements. This makes most of the previous ingredients un-like current cost control 
processes. None of these steps should be confused here with alternate systems such as Earned Value Management 
(EVM), use of confidence levels in cost estimating, Pert diagrams, scheduling tools, or other tools that have their 
place. The difference in this proposed Life-Cycle-Cost-Control methodology lies in emphasizing a future recurring 
operations cost projection, inclusive of productive flight rate or a similar metric, to guide current decisions and costs 
in design, development, test and engineering. Without such a view systems developments are condemned to 
emphasize near term costs to “get there”, the non-recurring capital expense day-to-day or any year, only to field 
systems that fail to make any advancement toward more routine, affordable, safer, access to space. 
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III. Recent Events 



Many SPST members, as is the case with this generation of NASA, industry and 
academia, have had the opportunity to participate in NASA programs beyond Apollo, 
Shuttle, or the International Space Station. NASA has had a host of programs since it 
began advertising the need to move beyond the Space Shuttle. The National Aerospace 
Plane or “NASP” program was one of the earliest initiatives, in the H early 80’s, once 
the Shuttle was flying, in regards to answering what comes next, what follows the 
semi-reusable Space Shuttle. Unfortunately, the NASP program would be the first of 
many initiatives in NASA to address the question “what next”? Figure 5 is testament 
to an assortment of NASA initiatives, all of which at one point or another sought out 
lessons learned, and all of which failed to become defined (to date) as what was to 
build on these past lessons and lead into the future. 

At the other end of the spectrum, with the Shuttle program scheduled to have two 
more flights as of this writing, NASA is in the midst of a re-direction that includes 
plans to cancel the last initiative at answering the same question - “what next”? The 
Constellation program has been l213 canceled in recent policy setting the NASA Fiscal 
year 20 1 1 budget. 

Prior to this shift in direction, since the more formal start of the Constellation 
program in 2006, a program defined by two Shuttle derived launch vehicles, there have 
been numerous analysis that have employed lessons learned in analyzing, modeling 
and assessment processes. One such process is the NASA Standing Review Board 
(SRB) process that has emphasized both independent cost estimation of the 
quantitative sort as well as assessment of the more qualitative sort. Here, lessons such 
as those previously presented here were incorporated into the analysis of the recurring 
operations of the Kennedy Space Center Ground Operations Project (GOP). 

Using a model, the Launch and Landing Effects Ground Operations (LLEGO) 
model, lessons that are technical and operational, and very similar to those previously 
highlighted here, have been turned into quantitative cost estimating relationships 
(CERs). At it’s most sophisticated level (that is currently an enhancement in work 
through 2010), a model that has turned lessons into CERs can be used to address 
confidence not just in a proposed budget, but also in the targeted launch rate that 
represents the reason for the entire project, the productivity. Figure 6 represents 
actual output from such a model and is an “existence proof’ that lessons learned, 
well organized and linked to outcomes that too often are left as results or goals, 
can be used in program processes (such as boards, independent reviews, etc) in 
quantifiable and credible ways. 


Figure 5: NASA false starts. 
A handful of representations 
of what would come after the 
Space Shuttle. 
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Figure 6: A sample output of the LLEGO model. Here uncertainty applies in 
the cost estimated by the model AND in the flight rate productivity. 
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The LLEGO model uses lessons that are technical (about complexity, reliability, and 
operability/maintainability), and when applicable any operations and supply chain practices (default to traditional 
“as is” ways of doing business, or as wholly different ways of doing business), to rack, stack and interact parts of the 
launch system design. The connection from lessons learned about complexity for example (previously stated as “1. 
Reduce the number of toxic fluids, 2. Increase system margin, 3. Increase the built in test capabilities of systems, 4. 
Reduce the number of confined, and/or purged spaces, etc) to dollars, and thus affordability and flight rate, is shown 
very notionally in Figure 7. 


The analyst 

gathers 

information 




The LLEGO Model 
Steps in the Structure 

Inputs interact... 


A LLEGO input 
screen asks 
" how many of 
these thrusters 
are there"? 

INPUTS 


► 


Parts count 
reflects on 
complexity 


Observations 

2. Alternately, the INPUT 
could have been "3" yet the 
costs could be overall lower 
than "2" IF a related INPUT 
on reliability for the 3 were 
sufficiently HIGHER. 


► 


BUT - some parts draw 
more or less attention in 
ground processing 
through launch. 


Figure 7: Converting a lesson into quantifiable support to programs and projects. 


IV. Lessons and Technology Development 

Beyond qualitative lessons, beyond models, no matter how quantifiable, lie further study, technology 
development and demonstration. The literature provides ample evidence that lessons learned about reducing 
complexity, increasing reliability, and making more operable and maintainable systems is possible and is not always 
at odds with performance concerns of propulsion thrust, Isp, or vehicle dry weight. 

Figure 8 shows hardware from an actual prototype seeking to create 14 simplified (reduced parts count, welds, 
interfaces) turbomachinery for cryogenic rocket application. 
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Figure 8: Turbomachinery & lessons learned about parts count: A Turbopump left, in use, as an 
example of current technology, and a Turbopump right, as a prototype consisting of just four pieces. 
The proittotype was called the SLIC or “Simple Low-cost Innovative Concept” by Rocketdyne. The 
SLIC turbopump reached speeds of 77,500 rpm, or about twice the Shuttle’s turbopumps. Rather than 
use ball bearings, the SLIC pump also explored hydrostaic bearing technology (again, fewer parts). 


Examples abound of how a lesson in rocket propulsion is to simplify, reducing parts count, having a more 
modular design, reducing welds and interfaces. Albeit, while technology may inevitably get increasingly more 
complex as it gets more capable, as more is demanded of it, historical analogies for most high performing 
technology would indicate that it’s possible to simultaneously achieve a greater ease of operation. The importance of 
increasing reliability is not lost in lessons learned, keeping the ill effects of complexity from overwhelming the 
objectives - affordability, and more routine, productive system operations. 

Along similar lines. Figure 9 from the US Air Force ^Integrated Modular Engine study is just one example of 
taking lessons learned to the next level of stsudy and design formulation. Such work is merely one example of where 
performance have been shown not to be at odds with lessons learned. The challenges associated with such system 
designs are about focusing the organization on the right “-ilities”. 

By way of further example, lessons such as reduced parts count have been implemented when designing even 

advanced liquid hydrogen turbopumps, the most challenging of 
applications. Figure 10 shows work from 1999 developing and testing an 
advanced liquid hydrogen turbopump where 16 “low parts count simplifies 
assembly”. Once again it can be obssrved that some lessons have surfaced 
to the top of the list. It remains a task for the propulsion community to 
develop and undersatand the entire list and to apply these lessons in further 
test and demonstration leading to operational, commercial systems. 

Lastly, reliability and operability can not be emphasized enough. If 
capability is to increase in propulsion, and the entire launch system (flight 
& ground), it is inevitable that reliability and operability lessons must be 
further adopted in systems design. Reliability issues are repeatedly 
surfaced in lessons learned exercises, stressing early design “test-fail-fix” 
cycles to deliver a product that is ready for operations. Reliability and 
reusability inevitably go hand-in-hand. 


Figure 9: Sharing turbomachinery. From the US Air Force Integrated 
Modular Engine Study, 1992. 


Table 1. I ME Requirements 


Propellants 

0»/Hl 

Thrust (Ibf) 

30,000 

Specific Impulse (sec) 

>470 

Reliability 

0.865 

Operability 

High 

Production and development costs 

Low 
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Figure 10: Turbomachinery simplicity: Above for a 
simplified liquid hydrogen turbpump design, taking to 
heart the lesson “reduce parts count”, vs. below, a current 
design. 


V. Issues for the Industry 

There are numerous issues for propulsion as an 
industry that have not been covered here under the topic 
of lessons learned. Policy issues include regulations 
(International Traffic in Arms, “ITAR” rules, etc), as well 
as competitive issues in contracting relating to spreading 
knowledge. Where research and development pursues a 
lesson learned, and this has been R&D fostered by a 
government agency, such information must also spread 
much as lessons learned are shared. 


VI. Conclusion 

Concluding, lessons learned in propulsion and launch systems abound. Teams such as the SPST have been 
instrumental in making sense of the abundance of lessons from individuals, studies, and organizations. Structure has 
been shown to be possible when thinking about lessons learned and turning them into useful knowledge. It has been 
shown that a leap to quantitative models that fundamentally rely on structured lessons learned have evolved and 
even made their way into some NASA decision support processes. As well, technology development has oftne run 
sucessfully with the lessons learned that are surfaced as most important in an attempt to change the fundamental 
nature of our launch systems. If the desire is to improve the launch systems affordability, reliability (safety) and 
productivity (flight rate per year), the design focus must seek out lessons learned about making systems easier to 
operate. Nonetheless, realizing significant barriers remain, it is recommended that: 

A. NASA should adopt a structure for lessons learned that cleanly seperates and organizes technical (design, 

flight, ground), business (leadership, management, programmatic) and strategic (policy, goals, 
regulation) lessons learned. 

B. There remains a wealth of lessons learned in the business realm that are often under-explored and under- 

appreciated for their effect on the enterprise. Improvements in the entire flow of information and 
materials that ultimately enable a propulsion/vehicle/ground system design, manufacture and operation 
are critical to furthering the “-ilities” of affordability, reliability and maintainability. The entire supply 
chain management from customer requirement to supplier and back is an area ripe for lessons learned as 
expansive and encompassing as efforts to date for the definition of technical lessons learned. 

C. There also remains a wealth of lessons learned in the realm of the strategic. Ideas about the competitive 

structure of industry are under-explored and under-appreciated. Though some work in this area (e.g., 
the 1 ^independent operator” paradigm) has defined a relation between improvements in design and 
strategic, competitive factors, there is ample work here still to do to surface the right lessons, categorise 
these and eventually take them to as mature a level as technical lessons. 
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